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Abstract 

Reactive systems are systems that maintain an ongoing 
interaction with their environment, activated by receiving 
input events from the environment and producing output 
events in response. Modern programming languages de- 
signed to program such systems use a paradigm based on 
the notions of instants and activations. We describe a li- 
brary for Standard ML that provides basic primitives for 
programming reactive systems. The library is a low-level 
system upon which more sophisticated reactive behaviors 
can be built, which provides a convenient framework for 
prototyping extensions to existing reactive languages. 

1 Introduction 

We consider in this paper the problem of programming 
applications containing reactive subsystems. A reactive sys- 
tem is defined as a system that maintains an ongoing in- 
teraction with its environment [21], activated by receiving 
input events from the environment and producing output 
events in response. Typical examples of reactive systems 
are user interfaces, required to coordinate the various user 
requests (from the keyboard, the mouse and other devices) 
with information coming from the application (enabling or 
disabling input components and so on). Such systems gen- 
erally decompose into independent parallel components co- 
operating to solve a given task, and exhibit a high degree of 
concurrency [16]. Because of this, programming reactive 
systems using traditional sequential languages can be diffi- 
cult, and one often turns to concurrent languages to simplify 
the programming task. 

In the past decade, a class of languages has emerged 
specifically for programming reactive systems, including 
imperative languages such as Esterel [5] and declarative 
languages such as Signal [20] and Lustre [12]. Those lan- 
guages are directly based on the model of reactive systems 



as being activated by input events and producing output 
events. Their approach to programming reactive systems, 
referred to as the reactive paradigm, is to divide the life 
of a reactive system into instants, which are the moments 
where the system reacts. They allow the programmer to 
write statements that depend on instants. For example, a 
program may wait for the third instant where a given event 
occurs, and so on. Instants provide a notion of logical time 
to which programs may refer. This is in contrast to lan- 
guages providing a notion of absolute (or real) time, for ex- 
ample Ada [1] with its delay statement. 

This approach to programming reactive systems via in- 
stants has an interesting consequence. Instants act as a 
global logical time for a program, and thus the end of in- 
stants provide a consistent configuration of the state of the 
program, where one can make decisions before the next ac- 
tivation. This in turns allows for a clean specification of 
preemption, whereby one reaction can abort another reac- 
tion executing in parallel [4] . 

This paper describes a library for the programming 
language Standard ML (SML) [24] that implements the 
essence of the reactive paradigm, as described by Boussinot 
[6]: the notions of instants and activations. It permits the 
definition of SML expressions that can be activated and that 
specify control points denoting the end of instants. 

The original purpose of the library was to help develop 
a reactive interface language for connecting user interface 
components, independently of the underlying window man- 
agement system. The library also has features that make it 
interesting in its own right. It is built from a very small set 
of primitives, simplifying the task of analyzing programs 
using the library. It provides a framework for reactivity that 
fits naturally with the mostly-applicative programming style 
of SML. It can be implemented without sizable extensions 
to the language (none if the implementation provides first- 
class continuations or a similar facility). More importantly, 
it provides an opportunity to study the interaction of reactive 



primitives with features missing from most existing reactive 
languages: higher-order functions and recursion. 

The library is intended as a low-level framework im- 
plementing basic reactive functionality upon which one 
may build more sophisticated machinery. It can be used 
to investigate and prototype extensions to existing higher- 
level reactive languages, extending for example Esterel with 
higher-order faciUties. Compilation for higher-level reac- 
tive languages is non-trivial, and using the reactive library 
as a target language for compilation, one can rapidly pro- 
totype extensions. Once a useful extension has been iden- 
tified, effort can be put into finding a compilation process 
that generates code as efficient as possible. 

The paper is organized as follows: the next section de- 
scribes the primitives implemented by the library; Section 
3 provides an example of reactive code written using the 
hbrary; Section 4 gives the operational semantics of the re- 
active primitives; Section 5 compares the library to existing 
reactive frameworks, and Section 6 concludes with a dis- 
cussion of future work. 

2 The reactive library 

In this section, we describe the reactive library and pro- 
vide simple examples. Primitives for creating and activat- 
ing basic reactive expressions are given, along with com- 
binators to create new reactive expressions by combining 
existing ones. 

2.1 Basic reactive expressions 

The central notion defined by the reactive library is that 
of a reactive expression. A reactive expression is funda- 
mentally an SML expression that defines instants. The ba- 
sic primitives are shown in Figure 1. The function rexp 
creates a reactive expression out of its argument (a unit 
-> unit function). Activating the reactive expression will 
evaluate the argument of rexp until a call to stop, which 
marks the end of the current instant. The next activation 
of the reactive expression will resume the evaluation from 
the last point where a stop was called, until either another 
stop is called or the evaluation terminates. As a simple 
example, consider the following: 

val exp = rexp (fn () => (print "FIRST\n"; 

stop ; 

print "SECOND\n") ) 

This code defines a reactive expression exp that prints 
FIRST the first time it is activated, and SECOND the second 
time it is activated. After the second activation, the reactive 
expression is terminated. 

To activate a reactive expression from SML code, one 
applies the function react, which returns true if the ex- 
pression is terminated and false otherwise. Activating a 



terminated expression has no effect. The function dup cre- 
ates a copy of the reactive expression, with its current state. 
Here's a sample session with the above example: 

- react (exp) ; 

FIRST (* first instant *) 

false : bool 

- val copy ^ dup (exp) ; (* make a copy *) 
val copy = - : rexp 

- react (exp) ; 

SECOND (* second instant *) 

true : bool (* rexp terminates *) 

- react (exp) ; 
true : bool 

- react (copy) ; (* activate the copy *) 

SECOND 
true ; bool 

The function react! repeatedly activates the reactive 
expression until it terminates. 

A reactive expression can furthermore relinquish control 
to another reactive expression, via the function activate. 
When a reactive expression calls activate on a reactive 
expression e, it effectively behaves as e until e terminates, 
at which point the reactive expression continues evaluation. 
For example, activating the reactive expression 

rexp (fn ()=> (activate (exp) ; 

print "DONE\n")) 

activates exp, stopping when exp stops. Once exp termi- 
nates, evaluation of the reactive expression continues and 
DONE is printed before the reactive expression itself termi- 
nates. 

2.2 Combinators 

Reactive expressions with a more complex behavior are 
created via combinators, which take existing reactive ex- 
pressions and produce new ones. Figure 2 presents the most 
important combinators implemented by the library. 

The combinator merge takes two reactive expressions 
ei and 62 and returns a new reactive expression e with the 
following behavior: when e is activated, it activates ei and 
then 62. The reactive expression e terminates when both 
ei and 62 terminate. For example, consider the reactive ex- 
pression: 

merge (rexp (fn ()=> (print "1"; stop (); print "2")), 
rexp (fn ()=> (print "A"; stop (); print "B"))) 

This reactive expression will print lA at the first instant, 
and 2B at the second, then terminate. Note that the order of 
activation of the branches of the merge is determined. This 
ensures deterministic evaluation of the reactive expression. 
Alternate orders of evaluation can be specified by defining 
micro-instants (see Section 2.4). 

The combinator rif takes a boolean- valued function 
and two reactive expressions ei and 62, and returns a new 
reactive expression e with the following behavior: when e is 
activated, the boolean- valued function is evaluated, and de- 
pending on the resulting value, either ei or 62 is activated. 
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Figure 1. Reactive primitives 



The reactive expression e terminates if the selected reactive 
expression terminates. Note that the boolean-valued func- 
tion is evaluated at every instant. 

The other combinators are are defined in terms of basic 
reactive expressions, and the combinators merge and r i f . 
Consider for example the combinator 1 o op . It takes a reac- 
tive expression e and creates a new reactive expression with 
the following behavior: upon activation, it saves a copy of 
e at its current state, and activates a copy of that saved ex- 
pression; if that copy terminates, a new copy of the saved 
expression is created and activated. We initially save a copy 
of e and work exclusively on that copy in order not to be 
affected by external activations of e by other reactive ex- 
pressions. The behavior just described can be implemented 
as follows: 

fun loop (e) = let val saved_e ^ dup (e) 

fun 1 {) = (activate (dup (saved_e) ) ; 
1 0) 

in 

rexp 1 

end 

2.3 Preemption 

Preemption refers to the possibility for one reactive ex- 
pression to force the termination of another reactive expres- 
sion executing in "parallel" [4], i.e. in another branch of 
a merge. This is achieved in our framework by the SML 
exception mechanism. The following example shows how 
one branch of a merge can force termination of the whole 
merge expression: 

exception Abort 
let val m_exp = 

merge (rexp (fn ( ) => (print "FIRST\n"; 

stop 0; 
raise Abort ) ) , 
loop (rexp (fn () => (print "SECOND\n"; 

stop ())))) 

in 

rexp (fn ( ) => (activate (m_exp) handle Abort => ())) 

end 

Since the second branch of the merge is a loop, it never 
terminates, and thus the merge would never terminate if a 
preemption was not performed by the first branch. 



2.4 Micro-instants 

It is sometimes necessary to consider a subdivision of 
the notion of instant, to provide for a finer level of control. 
The following primitives are used to manage those so-called 

micro-instants: 

val suspend : unit -> unit 
val close : rexp -> rexp 

Micro-instants are created by calling the function 
suspend instead of stop. A reactive expression 
that calls the function suspend is said to be suspended. A 
suspended reactive expression behaves just like a stopped 
one, unless it is wrapped with a close combinator Upon 
activation, a reactive expression created via a close 
combinator will repeatedly activate the wrapped expres- 
sion until it stops or terminates. Whereas the suspend 
function splits instants into micro-instants, the close 
combinator performs the dual operation of combining the 
micro-instants together into a single instant. 

For example, consider the following reactive expression: 

close (merge (rexp (fn ( ) => (print "SUSPENDING " ; 

suspend ( ) ; 
print "1"; stop () ; 
print "2")), 
rexp (fn ( ) => (print "A"; stop (); 

print "B")))) 

This reactive expression will print SUSPENDING Al at the 
first instant, and 2B at the second, then terminate. The 
merge combinator activates the first reactive expression, 
which suspends after printing SUSPENDING, and then ac- 
tivates the second reactive expression, printing A. At this 
point, the merge is suspended, because its first branch is. 
The close combinator forces the completion of the sus- 
pended reactive expressions, and thus the first branch re- 
sumes its activation, printing 1 and then stopping. The 
second branch is already stopped, so the merge and the 
close stop. At the next instant, 2B is printed in the stan- 
dard manner, and termination follows. 

There is an implicit close wrapping the reactive ex- 
pression to which react is apphed. It is therefore impos- 
sible to witness micro-instants at the level of the application 
that uses the reactive expression. 



val merge : rexp * rexp -> rexp (* parallel activation *) 

val rif : (unit -> bool) * rexp * rexp -> rexp (* conditional activation *) 

val halt : unit -> rexp (* simply stop at every instant *) 

val nothing ; unit -> rexp (* terminate immediately *) 

val loop : rexp -> rexp (* reactivate rexp upon termination *) 

val terminate : (unit -> bool) * rexp -> rexp (* activate rexp if condition is false *) 

val init : (unit -> unit) * rexp -> rexp (* call fn before every activation of rexp *) 

val await ; (unit -> bool) * rexp -> rexp (* block activation of rexp until true *) 

val when ; (unit -> bool) * rexp -> rexp (* activate rexp when true else stop *) 

val repeat : int * rexp -> rexp (* reactivate rexp a ' n' times *) 



Figure 2. Reactive combinators 



A common use for suspend and micro-instants is to 
suspend the activation of a reactive expression until infor- 
mation has been collected from the activation of other reac- 
tive expressions. For example, one can implement various 
broadcast communication mechanisms between reactive ex- 
pressions using micro-instants [6, 10]. 

3 An example: A simple keypad controller 

Let us now consider an example of reactive code in some 
detail. Interesting applications of the reactive approach are 
found in the programming of widgets for user interface 
toolkits, such as eXene [17J. Intuitively, a widget is an el- 
ement of a user interface that encapsulates some behavior. 
Basic widgets include buttons and text editing fields, and 
menus. More complex widgets can be build up from other 
widgets, like dialog boxes and so on. The obvious advan- 
tage of encapsulating behavior inside widgets is that they 
can be reused in different applications. 

Programming a new widget involves selecting the wid- 
gets it will be built from and then programming the control- 
ling behavior of the widget (also know as the controller), 
taking into account the input from its sub-widgets and the 
expected interface of the widget. The key observation is that 
the controller is fundamentally a reactive system. 

Suppose we want to construct a widget representing a 
numeric keypad made up of 

• ten push buttons for the digits; 

• a push button for CLEAR, that resets the number cur- 
rently entered to 0; 

• a push button for ENTER, that prints the number cur- 
rently entered and then resets it to 0. 

Suppose moreover that we parameterize the widget with re- 
spect to an integer n, representing the size of the number 
buffer (the number of digits it will accept). 

Here is how we could represent the behavior of the key- 
pad using the reactive library. We program the keypad con- 
troller as a reactive expression. We assume a mechanism 



that waits for windowing system events (such as button 
presses) and activates the controller if an event concerns 
it. To access the state of the world, we assume we have 
boolean- valued functions 

val kDigitPressed : unit -> bool 

val kClearPressed : unit -> bool 

val kEnterPressed : unit -> bool 

that inform us if the corresponding button has been pressed 
in the current instant and a function 

val kDigitValue : unit -> int 

that returns the last digit pressed^ 

We define a reactive expression for every button of the 
keypad. The full controller will simply be a merge of all 
these reactive expressions. This approach simplifies the task 
of adding new buttons to the keypad. The code for the con- 
troller is given in Figure 3. 

The reactive expression enter_rexp corresponding to 
the ENTER button is simple: At every instant, we check if 
ENTER has been pressed, if so, we print the number cur- 
rently entered, and then clear it and terminate. Otherwise, 
we stop and wait for the next instant. The reactive expres- 
sion clear _rexp handUng CLEAR is the same, except 
that we do not print the number currently entered. The re- 
active expression digit_rexp handling a digit waits for 
a digit to be pressed, and computes the new number before 
terminating. 

Recall that the keypad is parameterized by an integer n 
representing the size of the number buffer. We define a re- 
active expression getnum.rexp that will accumulate ex- 
actly n digits by activating digit_rexp exactly n times 
and then doing nothing for the subsequent instants after n 
digits have been pressed. 

All of these expressions are gathered together to form the 
full controller, which is obtained by applying the function 
mkController to an integer representing the desired size 

^No usable user interface toolkit would require us to access the state 
of the interface via such functions. We simply abstract away from the 
problem of communicating windowing system events via this artificial in- 
terface. 



fun mkController (n) = 
let exception Clear 
val num = ref (0) 

fun clear () = (num := 0; raise Clear) 
val enter_rexp = rif (kEnterPressed, 

rexp (fn ( ) => (print (Int .toString ( ! num) ) ; 

clear ())), 

halt 0) 

val clear_rexp = rif (kClearPressed, rexp (clear), halt ()) 
val digit_rexp = rif (kDigitPressed, 

rexp (fn ()-> (num: - ! num* 10+kDigitValue ())), 

halt 0) 

val getnum_rexp = rexp (fn ()=> (activate (repeat (n, digit_rexp) ) ; 

activate (halt ()))) 

in 

loop (rexp (fn ( ) => activate (enter_rexp | | clear_rexp | | getnum_rexp) 
handle Clear => () ) ) 

end 



Figure 3. Definition of the Iceypad controller 



of the number buffer. The core of the controller is the reac- 
tive expression that activates enter.rexp, clear.rexp 
and getnum_rexp concurrently'^. Since getnum_rexp 
never terminates, the merged expression never terminates 
by itself. However, the function clear is used to raise a 
Clear exception. When ENTER or CLEAR is pressed, the 
exception is raised and intercepted by the exception handler 
of the main reactive expression; the expression terminates 
and loops, awaiting for another button press. 

Suppose we wish to add a NEG button to the keypad, that 
negates the number currently entered. We need only provide 
a function kNegPressed, and a new reactive expression 
to handle this case: 



val neg_rexp 



rif (kNegPressed, 

rexp (fn ( ) => (num 
halt 0) 



• (!neg) ) ) , 



We can then add neg_rexp to the general merge of the 
keypad controller. It is also possible to parametrize the con- 
troller over the buttons and corresponding reactive expres- 
sions used to implement them. 

4 Operational semantics 

We describe the semantics of reactive expressions in 
terms of a simple functional language, in the spirit of 
[3, 27]. The syntax of the language is given by the following 
grammar: 

M = a; I I Ml M2 I (Mi, Mj) | (Mi; Ma) 

I (fn X => M) \ (rec f{x) => M) 

where x and / are alphabetic identifiers. The semantic ob- 
jects are given in Figure 4. As in [3], the set of expressions 
is a superset of both the set of values and the set of lexical 



phrases. The set of identifiers includes all possible alpha- 
betic identifiers, including the constructors and basic val- 
ues. The constructors and basic values define the reactive 
behavior of the language. They have no special syntax be- 
yond their existence as identifiers. The notation is used 
to denote a finite mapping. 

A reactive expression is tagged with a unique reactive 
ID: whenever a new reactive expression is created via rexp 
or by applying a combinator to existing reactive expres- 
sions, a new reactive ID is allocated and associated to the 
reactive expression. A reactive environment R S is used to 
store information relating to reactive expressions. The map 
R holds the bindings between reactive IDs and actual re- 
active expressions, stored as constructed values. The map 
S stores the current state of reactive expressions, indexed 
by reactive ID. The state of a reactive expression is either 
stopped, suspended or terminated. Given M a finite map, 
we use the notation M[m : v] to denote the new map de- 
fined by: 



M[m : v]{m') 



M{m') if m'^m 
V if m' = m 



^The operator | | is simply an infix version of merge, tliat allows for 
a clearer presentation of nested merged reactive expressions. 



The semantics is described used Plotkin's Structural Op- 
erational Semantics [26], and extends the semantics of Re- 
active C given in [7]. 

The semantics we describe has two levels. The first level 
is a semantics for the core language, given in Figure 5, ex- 
pressed as a conventional reduction rule semantics. The 
semantics of the core language is complicated by the fact 
that expressions can occur in two contexts: the normal se- 
quential context, and in the context of a reactive expression 
(captured by a rexp constructor). The reduction relation 

e,RS ^ e',R' S' 

denotes the reduction of expression e into expression e', 
possibly transforming the reactive environment R S into 
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Figure 4. Semantic objects 



R' S'. The reduction is labeled by an action a: END if 
the reduction terminates instantly, STOP if the reduction is 
stopped and SUSP if the reduction is suspended. Stopped 
and suspended reductions can only occur within the context 
of rexp constructed expression. 

As we already noted, the only reductions allowed for 
the core language in the normal sequential context are ter- 
minated reductions (labeled END). The function react is 
the only function that may be called from the sequential 
context. We do not give the semantics of react to un- 
clutter the presentation of the rules, but react behaves as 
activate in the sequential context — returning true or 
false depending on the resulting status of the reactive ex- 
pression to which it is applied. 

In the context of a reactive expression, the core language 
is allowed the full range of labeled reductions. The basic 
functions stop, suspend, activate and reset are 
allowed in such a context. 

The interesting rules in that part of the semantics are 
the rules for activate, which acts upon reactive expres- 
sions (really reactive IDs representing reactive expressions). 
The intuitive interpretation of activate is to activate the 
given reactive expression, which propagates the activation 
according to the structure of the reactive expression. 

The rules for activate involve the reduction relation 

r,RS ^ R' S' 

that act on a reactive expression whose ID is r. Again, the 
reduction is labeled by an action a indicating if the reduc- 



tion is terminated, stopped or suspended. The intuition be- 
hind this reduction relation is that if the reactive expression 
denoted by r is stopped, then the activation is not propa- 
gated, and activate returns immediately. If the reaction 
is not terminated, then the activation is propagated to the 
reactive expression via the reduction =^ . The reduction 
relation 1-^ is not formally necessary, but does greatly 
simplify the semantic rules. 

The actual activation of reactive expressions is expressed 
by the reduction relation 

r,RS ^ R' S' 

denoting the activation of the reactive expression whose ID 
is r. The rule to apply depends on the structure of the 
reactive expression, whose constructed value is extracted 
from the reactive environment. Again, this reduction rule 
is labeled by an action a indicating if the reaction termi- 
nates, stops or suspends. Figure 6 gives the semantics of 
reactive expressions. If the reactive expression is a rexp 
constructed value, the reduction of the expression involves 
the reduction of an expression in the core language via 
transitions. 

The semantics of the merge combinator use a function 
★ on actions, defined as follows: 
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Figure 5. Semantics of core language 



4.1 Implementation 

The implementation of the library is a direct transla- 
tion of the operational semantics. The core of of the im- 
plementation is a function step that plays the role of the 
transition in the semantics. It is used to activate a reac- 
tive expression and returns the state of the expression after 
the activation. Every basic combinator may be expressed by 
the step function and the basic reactive expression con- 
structor, by simply defining it via its semantic reduction 
rules. We therefore only need to concentrate on the imple- 
mentation of step, stop and suspend. 

The library was implemented with the Standard ML of 
New Jersey compiler [2]. The compiler provides callcc 
[22], an extension to SML that allows the expression of 
powerful control abstraction in a typed setting. It lets one 
grab the current continuation of the evaluation of an expres- 
sion as a first-class object and resume it at will. 

A reactive expression is implemented as a tuple contain- 
ing the continuation of the reactive expression and the cur- 
rent state of the expression. Calling step on the tuple sim- 
ply throws the stored continuation to resume the evaluation 



of the expression, after saving the current continuation. This 
latter continuation will be thrown if s t op is called from the 
reactive expression code. The function stop saves the cur- 
rent continuation of the reactive expression in the tuple, and 
throws the continuation saved by the step function, resum- 
ing the evaluation of the code calling step. The function 
suspend is similarly implemented. The technique used is 
analogous to the one used by Wand [29] and Reppy [27] to 
implement concurrent threads via continuations. 



5 Comparison with other reactive frame 
works 



The library described in this paper evolved from a de- 
sire to port the reactive framework of Reactive C [6] to the 
higher-order language SML. It is instructive to compare our 
system against both the original Reactive C and its deriva- 
tive, the Java toolkit SugarCubes [11]. We also compare the 
Ubrary to various other frameworks for programming reac- 
tive systems. 
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R(r-) = (rif,(^,n,T-2)) S(r-)7^SUSP v Q, R S ^ true,R' S' ri,R' S' ^ R" S" 

r,RS ^ R" S"[r : a] 

fi(r) = (rif,(^;,r-i,r-2)) S(r) 7^ SUSP v {), R S ^ talse,R' S' r2,R' S' ^ R" S" 

r,RS R" S"[r : a] 

R{r) = (ri.f,{v,ri,-}) S(ri) = SUSP ri,RS=^R'S' 
r,RS ^ R' S'[r : a] 

R{r) = (rif , {v, -, r2)) S{r2) = SUSP r2,RS =g» R' S' 
r,RS ^ R' S' 

R{r) = {close, r') r' , R S ^ R' S' a 7^ SUSP 
r,RS ^ R' S'{r : a] 

R(r) = (close, r') r',RS^R'S' r,R'S'^R"S" 
r,RS ^ R" S" 



Figure 6. Semantics of reactive expressions 



5.1 Reactive C and SugarCubes 

The principal difference between the formalism in this 
paper and the formaUsms of both Reactive C and Sugar- 
Cubes relates to the programming paradigm embodied by 
the underlying languages. The Reactive C formalism ex- 
tends the imperative language C [23] where programs are 
viewed as sequence of commands. The formalism defines a 
"machine" executing a sequence of reactive "instructions". 
The SugarCubes toolkit extends the object-oriented lan- 
guage Java [18], and also uses the same imperative ap- 
proach. 

To illustrate the differences between "reactive instruc- 
tions" and reactive expressions as we defined them in this 
paper, observe that our framework can be expressed as a 



datatype. Following SML's notation, one may define the 
following: 

datatype rexp - REXP of unit -> unit 
MERGE of rexp * rexp 
I RIF of (unit -> unit) * rexp * rexp 
... 

A reactive expression becomes a tree-shaped data structure, 
and react simply walks the given tree. In fact, the seman- 
tics of reactive expressions given in Section 4 uses exactly 
this view of reactive expressions as a constructed datatype. 
In this framework, the leaves of the structure are basic reac- 
tive expressions that contain arbitrary stop, suspend and 
act ivate calls. Sample reactive code would look like: 

MERGE (REXP (fn ( ) => (print "1"; stopO; print "2")), 
REXP (fn ()=> (print "A"; stopO; print "B"))) 



If we were to implement the reactive "instructions" ap- 
proach in SML via a datatype description as above, we 
would obtain something Uke the following: 

datatype rinst - EXP of unit -> unit 

I STOP 

I SUSPEND 

I ACTIVATE of rinst 

I SEQUENCE of rinst list 

I MERGE of rinst 

I RTF of (unit -> unit) * rinst * rinst 

We do not allow arbitrary calls to stop and suspend in 
basic expressions. Rather, the end of instants are explicitly 
specified in the datatype. Basic expressions always termi- 
nate immediately. This means that much of the structure 
that in our framework would fit in a basic reactive expres- 
sion REXP now needs to be exphcitly added to the datatype 
(for example, a way to describe sequences of reactive in- 
structions). The sample code given above would now look 
hke: 

MERGE (SEQUENCE [EXP (fn ()=> print "1"), STOP, 
EXP (fn ()=> print "2")], 
SEQUENCE [EXP (fn ( ) => print "A"), STOP, 
EXP (fn ()=> print "B")]) 

A reactive library implemented via reactive instructions (us- 
ing the model of SugarCubes) is part of the Standard ML of 
New Jersey Library^. 

The first approach, which we followed in this paper, al- 
lows for a clearer syntax, by directly using SML control- 
flow primitives (sequencing, local declarations) which need 
to be redefined in the datatype for the second approach. 
Moreover, the first approach allows one to easily reuse ex- 
isting higher-order functions in a reactive way. One can 
easily write: 

REXP (fn ()=> app (stop o print) [ " 1 " , "2 " , " 3 " , " 4 " ] ) 

which prints one number of the list at every instant until ter- 
mination. Expressing this reactive expression in the second 
approach seems difficult. On the other hand, the reactive 
code in the second approach is easier to analyze (for the 
purpose of compilation, for example), since the end of in- 
stants is fully characterized by the actual data structure rep- 
resenting the reactive code — there is no need to analyze the 
control-flow of an arbitrary SML expression caUing stop 
and suspend. 

5.2 Synchronous languages 

Synchronous languages are among the most popular lan- 
guages for programming reactive systems. These include 
Esterel [5], Lustre [12] and Signal [20]. These languages 
are aU based on the same notions of instants and activations 
that we describe in this paper, but with important additions. 
In the case of Esterel, we have the foUowing: 

'j. Reppy, Personal communication, 1997. 



1. The instants are assumed to take zero time and are 
atomic. This is the synchrony hypothesis. 

2. Communication between parallel reactions is done via 
broadcast signals, and is instantaneous. 

3. Preemption can be triggered by the presence of a spec- 
ified signal in the instant under consideration. 

These characteristics allow the code for Esterel (and syn- 
chronous languages in general) to be efficiently compiled 
into a finite-state automaton, which can be translated into 
a program in a sequential language. There exists a transla- 
tor taking the output of the Esterel compiler into SML code 
implementing the corresponding finite-state automaton"*. 

Our framework does not support the synchrony hypoth- 
esis of synchronous languages, and provides no commu- 
nication mechanism between various parallel reactions be- 
yond shared memory. As such, it does not support com- 
pilation into finite-state machines, and can be considered 
lower-level than synchronous languages. Boussinot and de 
Simone showed in [9] that it is possible to translate a syn- 
chronous language into a framework similar to the one de- 
scribed in this paper. This justifies our intended goal of us- 
ing the Ubrary as a target language for experimental exten- 
sions to synchronous languages, such as higher-order syn- 
chronous languages. These extensions might not preserve 
finite-state semantics, but may still be useful as a conve- 
nient notation for various types of processes. 

Higher-order extensions to synchronous languages in- 
clude the work of Caspi and Pouzet [13] on extending the 
dataflow synchronous language Lustre with higher-order 
functions. 

5.3 Fran 

The Fran system [15] is a reactive framework for pro- 
gramming multimedia animations in Haskell [25]. It defines 
the notions of behaviors and events to program reactive an- 
imations. A behavior is fundamentally a function of time, 
and it is possible to specify behaviors with respect to events. 
The principal difference between the Fran approach and the 
one in this paper is that Fran is based on a continuous time 
model as opposed to our discrete time model divided into 
instants. 

5.4 Coroutine facilities 

Languages providing faciUties for defining coroutines 
can be used to define a reactive framework such as the one 
we present in this paper. For example, the programming 
language Icon [19] provides co-expressions, which are ex- 
pressions that can be suspended and resumed at a later time. 

'^L Riecke, Personal communication, 1997. 



When it suspends, a co-expression needs to state to which 
other co-expression it is relinquishing control. Our basic 
notions of activation and instants can be viewed as a hierar- 
chical use of co-expressions. 

6 Future work 

The interesting questions about the framework presented 
in this paper all relate to the interaction between the reactive 
formaUsm and the underlying mostly-functional approach 
of SML. For example, the current implementation of the 
rif combinatoruses a (unit -> unit) function to be 
evaluated at every instant to determine which branch of the 
reactive conditional to activate. This means that any exter- 
nal value used by the test must be a reference. 

Possible extensions to the framework include adding pa- 
rameters to react that will be propagated through every 
combinator and used by rif during the evaluation of the 
conditional test. Dually, we can give a return type to re- 
active expressions, so that a value may be returned when 
a reaction stops or terminates. One should then augment 
the merge combinator with a function specifying how to 
combine the values returned by the two branches. 

Futher investigations into the interaction between reac- 
tivity and higher-order functions will involve the implemen- 
tation of the reactive framework as a monad [28] in the 
purely functional language Haskell. Work by Claessen [14] 
on expressing concurrency as a monad via explicitly inter- 
leaved atomic actions closely follow our merge combina- 
tor. It would also be of interest to embed the reactive frame- 
work in a typed A-calculus, in a way similar to the semantics 
of reactivity given in terms of a process calculus in [8]. 

7 Conclusion 

We have described in this paper a reactive library for 
SML that implements the reactive paradigm exemplified by 
modem languages such as Esterel. The library provides 
primitives that capture the essence of the reactive paradigm, 
namely the notions of instants and activations. The library 
is intended to be a low-level system upon which more so- 
phisticated reactive behavior can be built, providing a con- 
venient framework for prototyping various higher-level re- 
active languages. 
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